home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2989 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.0 KB  |  84 lines
  1. Newsgroups: comp.lang.c++
  2. Path: netcom.com!marnold
  3. From: marnold@netcom.com (Matt Arnold)
  4. Subject: [Q] Best way to "define" flag values?
  5. Message-ID: <marnoldDLIv9w.1s4@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. Distribution: na
  8. Date: Sun, 21 Jan 1996 08:22:44 GMT
  9. Sender: marnold@netcom.netcom.com
  10.  
  11. Hi,
  12.  
  13. I know many C++ programmers strive to use the C preprocessor as
  14. little as possible, employing C++'s many language features instead.
  15. For example, most functional macros are much better implemented as 
  16. function templates in C++.
  17.  
  18. Another area where C++ programmers can avoid using C macros is
  19. when defining the constant numeric values used in their code.
  20. Instead of "#define THE_ANSWER 42", enums or const data values can
  21. be used with better type safety, etc..
  22.  
  23. However, I have never quite found a good substitute for declaring
  24. values for flags.  Passing flags to a function, for instance, is
  25. a very common construct, and it's typically arranged like so...
  26.  
  27.    #define FLAG_A 0x0001
  28.    #define FLAG_B 0x0010
  29.    #define FLAG_C 0x0100
  30.  
  31.    void FuncTakingFlags(unsigned flags);
  32.             .
  33.             .
  34.             .
  35.    FuncTakingFlags(FLAG_A | FLAG_B);    // example usage
  36.  
  37.  
  38. I suppose what I am after is a way to automatically define flags, 
  39. in the same fashion that an enum can be used to "automatically" 
  40. generate unqiue numeric values...
  41.  
  42.    enum { A, B, C };
  43.  
  44. For example, A, B and C are all guaranteed to be different values 
  45. and, I as a programmer don't even have to worry what they are if I 
  46. don't need to.  And, I can extend the value set by simply adding 
  47. another member to the enum.  Undoutbly, this is somewhat "cleaner" 
  48. than #define-ing (or whatever) values manually.
  49.  
  50. I've though about using enum behavior to automatically create flags,
  51. using something like the following...
  52.  
  53.    enum
  54.       { 
  55.       flag_bit_a,    // NOTE: relies on first enum member being zero
  56.       flag_bit_b,
  57.       flag_bit_c,
  58.   
  59.       FLAG_A = 1 << flag_bit_a,  
  60.       FLAG_B = 1 << flag_bit_b,
  61.       FLAG_C = 1 << flag_bit_c
  62.       };
  63.  
  64. But, this seems to be just as "messy" and just as error-prone as 
  65. the age-old #define approach and doesn't really seem to buy much.
  66. Plus, it intoduces "implementation" identifiers into the namespace
  67. (all the "bit" values used to create the flag values above).
  68.  
  69. How do others deal with flags in their programming, especially
  70. when creating "API" or library functions for which passing flags
  71. is really the only choice (course, I am open to hearing about 
  72. methods that even avoid flag values).
  73.  
  74. Thanks for any advice or comments.
  75.  
  76. Regards,
  77. -------------------------------------------------------------------------
  78. Matt Arnold                       |        | ||| | |||| |  | | || ||
  79. marnold@netcom.com                |        | ||| | |||| |  | | || ||
  80. Boston, MA                        |      0 | ||| | |||| |  | | || ||
  81. 617.389.7384 (h) 617.576.2760 (w) |        | ||| | |||| |  | | || ||
  82. C++, MIDI, Win32/95 developer     |        | ||| 4 3 1   0 8 3 || ||
  83. -------------------------------------------------------------------------
  84.